Behaviour Specification in Database Interoperation

We discuss the impact of locally implemented behavi0ur in a federation of object-oriented databases. In particular, given a specification of an integrated view of a number of component databases, we discuss the process of determining the global methods that are implicitly implemented by a given set of local methods on these component databases. To this end, we develop the notions of objectivity and subjecti~i~y of local methods, indicating whether the execution of a local method affects the global view exactly as it affects the local database, behaviour equivalences between local methods, indicating whether local methods of different components have similar effect, and behaviour concurrences, indicating whether local methods respond to the same event. 1 I n t r o d u c t i o n So far, database interoperation research has focused on the structural aspects of data integration. Even though the use of an object-oriented data model as the canonical model for interoperation has been widely advocated [6], attention for the extended structural modelling capabilities of such models has overshadowed their behavioural aspects. That is, object-oriented multidatabase management systems generally do not present object methods other than those implementing generic query and transaction facilities to a global user, in spite of the fact that component databases may have implemented application-specific methods with their local objects. In this paper, we investigate to what extent such locally defined methods can be incorporated in the global object view definition. It would be attractive to offer global applications a global method interface with comparable functionality. Such global methods, however, are virtual in the sense that they are implemented by calling the appropriate local methods at (multiple) component databases. 1.1 Approaches to behav iour in da tabase in te ropera t ion Many types of research can be regarded as somehow addressing behaviour in the context of database interoperation. We discuss three of them here. In [3], Bertino et al. distinguished between structural and operational mappings. It was argued that operational mapping is a good alternative if a structural mapping cannot be achieved, for example if one of the systems to be integrated is not a DBMS. A global user is then presented with a set of operations rather than an integrated schema. In contrast, in this paper we discuss behavioural issues that arise once a structural integration has been performed. Another idea is to use semantical information provided by method definitions to guide the process of schema integration [8]. Although this is an interesting